Performing a static code analysis

This article is about the static code analysis that must be performed before an application is built/loaded. This static code analysis is required in addition to the verification and validation stages that is required by the "Safety instructions on working with the IDE".

As the static code analysis for the library is automatically triggered when the Neuron Power Engineer library is generated (see "Creating and deploying a library), it is not necessary to start the static code analysis for a library yourself. Nevertheless, this article contains the instructions to perform the static code analysis for a library as well, if you might want to perform a static code analysis before creating the library.

How to perform a static code analysis:

1. Activate the rules that need to be examined during the static code analysis. Details: See Neuron Power Engineer user documentation, "Rules for the validation of an application" for a list of provided rules.
   Contact the system integrator for information on the minimum set of the activated rules.

   1. In the case of an application, the rules must be activated for the→resource.

   2. In the case of a library, the rules must be activated for the →project. 

2. Start the static code analysis by validating all elements in the appropriate context. Details: See Neuron Power Engineer user documentation, "Validating objects", section "Validation relating to the instance" or "Validation relating to the library".

   1. In the case of an application, these elements are all application elements in the context of the resource. This means that you need to execute a static code analysis relating to the →instance.

   2. In the case of a library, these elements are all library elements in the context of each library. This means that you need to execute a static code analysis relating to the library.

3. Make sure that the MRC-report is generated and that it contains the expected information. See Warning 1.
   The MRC-report is a report with the file extension .mrclog. Details: See Neuron Power Engineer user documentation, "Results of examination in Validate view" for the location of the MRC-report.

4. In the case of an application: Keep this MRC-report of the static code analysis because the names and fingerprints of the elements in this MRC-report will need to be compared with the information contained in the build report.
   In the case of a library: Just keep the MRC-report of the final static code analysis when the library is generated because the names and fingerprints of the elements in this MRC-report will need to be compared with the information contained in the library generation report.

Warning 1 The MRC-report contains the following information about the executed static code analysis: Example for MRC-report  Observe that the illustration is an example. Your actual report might be different and/or contain additional information/sections.  Check the following information in your MRC-report: the number of errors, warnings and information Make sure that no errors are reported. If errors are listed, fix them and repeat the static code analysis. In the case that there are only warnings and/or infos, contact the system integrator and clarify the necessary course of events. the rules and their activation/configuration state Make sure that the required rules have been activated with the appropriate severity (ERROR, WARNING or INFO). Make sure that there are no occurrences of rule violations. If yes, fix them and repeat the static code analysis. the names and the →fingerprints of each application element There is no need to check these pieces of the following information in this phase but they are needed later on. Reason: In the phase "Building and loading the application onto the PLC" or "Creating and deploying a library", you will need to compare the names and fingerprints of the elements in this MRC-report with the information contained in the build report or the library generation report.